Software defects caused by coding errors occur through the processes of a programmer making a mistake, which results in a defect in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure. Not all defects will necessarily result in failures (e.g. defects in dead code). However, a defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new computer hardware platform, alterations in source data, or interacting with different software. A single defect may result in a wide range of failure symptoms.
Clearly the increased complexity of software systems nowadays amplifies the probability of software defects, for various reasons. However, there is also a constant pressure to reduce software development time and increase the quality of the software. One way of preserving quality while reducing cost is to optimize the testing process of the software.
In some cases, Quality Assurance (QA) personnel may have to focus their attention at specific elements of the software, such as test those elements, manually review the code of the elements, or the like. Additionally, in case there is a given test suite, only a subset of the tests may be activated to test the system in order to decrease testing time. To this end it may be desirable to identify the more error prone elements, so that the limited available testing and review resources can be mostly allocated for these components.
Some QA personnel may focus on re-checking a software element which has exhibited a defect in the past. However, such methodology does not help in identifying error prone elements whose defects were not yet discovered. That methodology is also not helpful in identifying the more error prone elements out of a collection of new elements introduced to the software.